<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 14 March 2014 14:49, Jim Perrin <span dir="ltr"><<a href="mailto:jperrin@centos.org" target="_blank">jperrin@centos.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
On 03/14/2014 12:26 PM, Stephen John Smoogen wrote:<br>
> I would like to put together an alternative desktop sig which will build,<br>
> qa, and support desktops which are not the Enterprise Linux primary or<br>
> secondary desktops (GNOME and KDE).<br>
<br>
</div>Fantastic!<br>
<div class=""><br>
> There are a couple of ground rules I would like to propose:<br>
><br>
> 1) Any desktop system needs to have 3 sponsors who are people willing to do<br>
> the work of building RPMS, coordinating user bugs with upstream, and fixing<br>
> packages. The reason for 3 is<br>
>   a) that this SIG isn't a dumping ground for here is ABC-DE compiled,<br>
> goodbye.<br>
>   b) that disagreements between sponsors should be deadlock free.<br>
>   c) that when people take vacations, etc there is continuity of operation.<br>
<br>
<br>
</div>How would this apply to something like EPEL, which in el6 has XFCE<br>
packaged. Would it be acceptable to pull that in, or would that simply<br>
count as 1 of the 3?<br>
<div class=""><br></div></blockquote><div><br></div><div>That was something that I figured would also need to be planned for. Where do these packages live? Who is caring for them? My initial viewpoint is that it would be nice if the people on a desktop were co-maintainers on the package set if it were in EPEL. The main thing is to try and make sure that stuff gets accidentally abandoned.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> 2) Desktops do not keep to Enterprise lifetimes, but major version changes<br>
> to the desktop need to be announced, tested and released to a schedule.<br>
> Desktops which don't want to do that will not be part of the SIG. [A<br>
> schedule does not need to be super detailed, but just alleviate surprise.]<br>
> 3) Desktops can and will be removed from the SIG if there isn't an interest<br>
> in keeping them up. This is mainly to cover that if ABC-DE desktop no<br>
> longer has sponsors, other members of the SIG aren't obliged to support<br>
> ABC-DE if they don't want to.<br>
<br>
</div>I would propose that anything being removed be treated as a major<br>
version change, with an announcement and warning for users.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Yes I agree on that. It is a major change and would need an announcement and warning to users.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
> 4) Some level of governance needs to be established so that there is a<br>
> committee that can make sure that a desktop has 'sponsors', that it is not<br>
> just code thrown over a wall and left, and that users are not left<br>
> surprised when updates to the desktop occur. They may also make up<br>
> packaging rules and guidelines as needed to alleviate problems that come up.<br>
><br>
> As this is an RFC, these are just proposed rules to be solidified when the<br>
> CentOS board considers the SIG.<br>
<br>
<br>
<br>
<br>
--<br>
</div></div><span class="HOEnZb"><font color="#888888">Jim Perrin<br>
The CentOS Project | <a href="http://www.centos.org" target="_blank">http://www.centos.org</a><br>
twitter: @BitIntegrity | GPG Key: FA09AD77<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Stephen J Smoogen.<br><br></div>
</div></div>