My 2 most-wanted MailNews Core updates, in Thunderbird 3.1 cycle !?
Serge Gautherie
Here two areas that I'm really hoping for (for some time),
and I wonder if they could fit in the TB 3.1 cycle:
Bug 506601 Create an own hg repository for directory (= ldap)
https://bugzilla.mozilla.org/show_bug.cgi?id=506601
See discussion in m.d.t.ldap.
Bug 377319 - Convert mailnews to frozen/external linkages
https://bugzilla.mozilla.org/show_bug.cgi?id=377319
The switch to full libxul could then happen in TB 3.2...
Thanks.
Dan Mosedale
> Hi,
>
> Here two areas that I'm really hoping for (for some time),
> and I wonder if they could fit in the TB 3.1 cycle:
>
> Bug 506601 Create an own hg repository for directory (= ldap)
> https://bugzilla.mozilla.org/show_bug.cgi?id=506601
> See discussion in m.d.t.ldap.
"good enough", given the amount of action the LDAP code sees these
days. Unfortunately, since we don't have a bonsai-like tool for
Mercurial, I'm having a hard time verifying for myself whether that
hunch is actually true. Is there some specific piece of work you're
aware of that would significantly benefit from such a move?
Dan
Ben Bucksch
> On 12/18/2009 5:12 PM, Serge Gautherie wrote:
>> Bug 506601 Create an own hg repository for directory (= ldap)
>> https://bugzilla.mozilla.org/show_bug.cgi?id=506601
>> See discussion in m.d.t.ldap.
> I'm having a hard time convincing myself that the current setup isn't
> "good enough", given the amount of action the LDAP code sees these days.
I also would like to finally say good by to CVS. This is the last CVS repo.
Also because that makes securing (https) easier. I *really* don't want
to fetch source that I'll run over entirely unprotected links.
(Before someone says it: Yes, Python 2.6 which checks signatures is now
widely deployed since a longer time.)
Add to that, I'd like a hg c-c setup which tracks the other repos (m-c
esp.) with a hg feature, versioned. I had repeated build failures on try
server (and other users of my repo), because m-c repeatedly changed
incompatibly. If I make a branch of c-c, and it builds for me on day X,
I want it to build on day X+10 as well, for me and others. I also
typically want the newest m-c (which is a contradiction), so that should
be an option, too. That's why it's good to use a VCS feature for
tracking rather than client.py. But a precondition of that is typically
that all sources use the same VCS system.
Ben
Serge Gautherie
> Is there some specific piece of work you're
> aware of that would significantly benefit from such a move?
As I'm not monitoring LDAP activity,
I can only say that there is at least a few bugs I filed (or I'm
interested in) that I won't look into (anymore) as long as the vcs is cvs.
The technical goal being to get rid of cvs and need hg only, both on
tinderbox builds and to work with locally.
I thought "I" had eventually managed to "convince" everybody to switch
over to hg: at least, the 3 extensions SeaMonkey packages have now.
Per discussion in m.d.t.ldap, it looked like LDAP was only waiting for
TB 3.0 to be released...
Dan Mosedale
> Dan Mosedale wrote:
>
>> Is there some specific piece of work you're aware of that would
>> significantly benefit from such a move?
>
> As I'm not monitoring LDAP activity,
> I can only say that there is at least a few bugs I filed (or I'm
> interested in) that I won't look into (anymore) as long as the vcs is
> cvs.
> The technical goal being to get rid of cvs and need hg only, both on
> tinderbox builds and to work with locally.
>
> I thought "I" had eventually managed to "convince" everybody to switch
> over to hg: at least, the 3 extensions SeaMonkey packages have now.
> Per discussion in m.d.t.ldap, it looked like LDAP was only waiting for
> TB 3.0 to be released...
making this change. The point I was trying to make was that signing up
for this work implicitly costs time from a number of people, probably at
the very least Standard8, gozer, and KaiRo, and maybe others as well.
For each of those people, I can imagine ways that they could invest
their time that offers significantly higher value to significantly more
Mozilla developers.
That said, I believe my objection was premature, in the sense that the
folks I mentioned are the only ones who have insight into the details of
how much time and effort it would likely cost them and what they'd be
trading that time against. I'll let them respond...
Dan
Mark Banner
I agree this is something we want to do, and although TB 3 is out, we're
doing lots of catch up on build admin stuff (like setting up TB 3.1 on
1.9.2), and as the current LDAP situation "works" it therefore has been
pushed down the priority order.
We need to consider a few things like buildbot setups and not breaking
stable branches etc, but I suspect most of this just needs co-ordination
with the LDAP team and then co-ordination with the comm-central projects.
Given the current workload on the TB side, I think we could pencil this
switch in for late January/early February once 3.0.1 is out and we've
completed builds for 3.1a1.
Standard8